sync: batch small files, skip unchanged manifests, probe presence on its own - #26

…its own

Performance
- Batched pulls (protocol revision 2): small files are fetched up to 256
  per request (4MB), 4 requests in flight, over a new /api/p2p/files
  route. Each file is still written through the PatchWriter (verified,
  fsynced, renamed). One request per file cost ~200ms on a real LAN; on
  loopback 5000 files went from 42s to 12s. Peers below revision 2 and
  relay connections keep the per-file path.
- Unchanged games: when this device still holds the agreed base, the
  manifest request carries ifHash and a peer that still holds it too
  answers "unchanged" instead of sending the manifest. Older peers ignore
  the parameter; their full answer is used, not fetched twice.
- Manifests are gzipped for clients that accept it (every Go client does,
  so older versions read them too): ~5.6x smaller with real hashes.
- Manifests and batches get a 10-minute client timeout instead of 30s; a
  large manifest over a VPN never arrived inside 30s, so those games
  never synced.
- An in-sync pass also mirrors the peer's latest snapshot, which only a
  pull did before; games identical everywhere from the start showed
  history on one device only.
- A batch is bounded by what the responder counts (each requested block at
  the file's full block size, at most the file's real size), so a batch of
  many small files with a few larger ones is never refused as too large; a
  batch refused anyway is fetched again as two halves.

Robustness
- Presence: paired LAN peers are probed every 10s on their own ticker.
  Probes used to ride along with the minute-long reconcile, which waits
  for a whole sync-all pass; peers reached over a VPN (no UDP broadcast)
  showed online/offline minutes late. Probe rounds are serialized.
- Games whose save folder is not on this device are skipped by sync-all
  and dropped from the retry queue instead of failing every 20s.
- "syncing X with Y" is logged only when there is something to do; most
  passes produced only "already in sync" lines, which rotated everything
  else out of the log within hours.
- The interrupted-pull safety test also runs over batched pulls.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…kept yet

An in-sync pass shares the peer's latest snapshot so a game identical
everywhere from the start (Steam Cloud, a copied folder) has history on
every device. It mirrored it whenever the peer's latest snapshot was newer,
also on a device that already keeps a snapshot of its save as it stands: a
second copy of the same save, named as synced from a peer that sent
nothing. Even the peer's first snapshot of an empty folder was taken this
way. Found by TestLauncherFile_SteamRewritingRemotecacheIsNoSaveChange,
which failed or passed depending on which device tracked the game a few
milliseconds later (always on Linux and Windows CI for Liquid-co#27).

The mirror is now taken only where this device keeps no snapshot of the
current save yet: the content recorded with its last snapshot (the
watcher's baseline) is not the content now (keepsCurrentSave). Same in the
quick "unchanged" path.

Test: TestSync_InSyncDoesNotMirrorASaveAlreadyKept fails without the check;
TestSync_InSyncMirrorsPeerSnapshot still passes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>